The present invention relates in general to information handling systems and more particularly to an apparatus and method for demand load analysis. Specifically, the present invention relates to an apparatus and method for selecting from a computer application program one or more dynamic link libraries (DLLs) to be demand loaded and for determining the benefit gained from demand loading a DLL or set of DLLs.
A computer application program usually includes a number of separate routines. Typically, the routines include a main program and several subsidiary routines referred to as objects, modules, or resources. Execution of the application program begins with the main program with calls being made to the subsidiary routines. To operate as a complete program, prior to execution these routines are linked together using a linker such as 386 link. The linker copies each of the routines into an executable file for the application program. The linker also provides each of the routines with information identifying the locations of other routines so that the routines can access each other. The executable file can then be loaded into the memory of a computer such that the application program can be executed by the computer according to the instructions in the routines.
A dynamic link library (DLL) is an executable module or routine containing services that application programs can call to perform useful tasks, e.g., directory searches, login commands, searching functions, character string manipulations, etc. DLLs exist primarily to provide services to application programs. These libraries play an important role in operating systems such as Windows and OS/2, which use them to make their services and resources available to application programs.
DLLs are similar to run-time libraries. The main difference between DLLs and run-time libraries is that DLLs are linked with the application program at run time, that is, when the computer is executing the application program, not when the application program files are linked with the linker. Linking a library with an application program at run time is referred to as dynamic linking; linking a library with an application program by using the linker is referred to as static linking. The discussion below focuses on the OS/2 operating system (OS/2 is a trademark of International Business Machines Corporation), but those of ordinary skill in the art will understand that the following discussion applies equally to other operating systems, such as Windows, which utilize DLLs.
To access a DLL at run time, the application program must be able to obtain information indicating where to find the DLL. One method provided by operating systems utilizing DLLs is to use an import library, or reference library, which contains information regarding where to locate the DLL at run time. During linking, the linker uses statically linked reference libraries to resolve references to external services. As noted above, when an application program desires a service from a static link library, the linker copies the code for that service into the application program""s executable file. When the application program desires a service run from a DLL, however, the linker does not copy any code from the DLL. Instead, the linker searches all defined import or reference libraries to find one that contains the necessary information regarding location of the DLL. The linker copies the necessary information from the reference or import library to create a dynamic link between the executing application program and the DLL.
When a process loads under the OS/2 operating system, all DLLs that the process references, either directly or indirectly, are also loaded. DLLs referencing other DLLs form a reference tree, the entire set of which gets loaded before the first instruction of the main program is executed. A typical DLL is only partially loaded. The remainder of the DLL is loaded on its first reference. The minimum DLL load requires some initialization in the operating system and the execution of the DLL""s initialization routine. Any code or data referenced by the initialization routine, including the initialization routine itself, is loaded. For some DLLs, the dynamic link load time is quite expensive in terms of time, particularly if the DLL is very large or the DLL""s initialization routine is very long.
The problem with load time initialization as described above is that frequently a process does not call the DLLs that it references. Therefore, the DLLs which are referenced but not called are unnecessarily loaded. When the load time of the unnecessary DLLs is a large percentage of the total execution time, the performance of the process degrades significantly.
There is a method utilized in the OS/2 operating system to prevent the unnecessary loading of DLLs. The method is called demand loading and is implemented using a well-known documented set of OS/2 operating system APIs (Application Program Interfaces). Demand loading is the process of delaying the load of a DLL until it is actually called. If a DLL is demand loaded but never demanded or called, it is effectively not loaded, and the cost of loading it is saved.
It will be appreciated that demand loading is utilized in other operating systems and creates problems similar to those encountered with the OS/2""s demand loading technique.
The problem with the OS/2""s demand loading technique is that it is difficult to use, particularly if a program has initially been written without it. It requires the programmer to replace a call to a target dynamic link with a load check, a couple of OS/2 demand loading APIs, and error recovery should the OS/2 APIs fail.
In U.S. patent application Ser. No. 08/742,103, U.S. Pat. No. 6,003,095, of common assignee herewith, an apparatus and method for automatically generating xe2x80x9cdemand loading codexe2x80x9d necessary to implement an operating system""s demand loading APIs is disclosed. The resulting code is packaged into a library which replaces a statically linked DLL reference library. In this manner, the called DLL is not changed in any way, but a tool is run against it to automatically generate a demand loading library for demand loading the DLL.
Performance analysis of a large software system with many DLLs can be very difficult. Many kinds of information are needed for the OS/2 operating system (OS/2 is a trademark of International Business Machines Corporation). A dekko hook/trace tool provides some, but not all, of the needed information. The dekko hook/trace tool provides timing information on both operating system events as well as user-written events. The dekko hook/trace tool searches the syntax of a C source file for the entry and exits of routines and automatically inserts dekko hooks. One of the problems with the dekko hook/trace tool, and the suite of utilities that thus far have been written for it, is a mechanism to easily and automatically apply dekko hooks to new code has not been provided.
Other non-dekko based performance tools have tried to solve the automatic and ease of use hooking problem, but each having been lacking in some respect. One particular problem is that prior art tools require some level of access to the source files used to build the executable of interest. Another problem is the processing overhead prior art tools introduce in the software being analyzed. For example, a dekko hook/trace tool requires access to source code so it can be temporarily modified and recompiled. The IBMCPP Performance Analysis Tool requires a recompile of the source code with a compiler switch indicating to enable tracing. IBMCPP Performance Analysis Tool is a tool which automatically hooks the entry and exits of routines and uses its own private trace log. MTrace is an instruction level trace tool which counts the number of instructions executed and accounts them to routine names. The MTrace tool does not require access to the source code but does require a symbol table generated when the executable of interest was built and thus cannot be applied to off-the-shelf products. It is also difficult to set up and generates too much detail for some long-running scenarios. It does not provide real timing information, just instruction counts, and introduces a large amount of overhead.
In U.S. patent application Ser. No. 08/763,136, U.S. Pat. No. 5,946,486, of common assignee herewith, a source code independent tool for hooking or tracing entry or exit points of DLLs is described. The tool only uses information that can be pulled from the DLL file itself. No source code access is required, so the tool is very convenient to use. In fact, having the ability to hook a DLL""s entry and exit points is very useful in helping to answer demand load questions, such as where, or to which set of DLLs to apply demand loading and how much benefit comes from demand loading.
What is needed is an apparatus and method for answering these two questions and, in general, for performing demand load analysis.
Accordingly, the present invention provides a method and apparatus for demand load analysis. The present invention is implemented in part by customizing the hooking tool described in APPARATUS AND METHOD FOR TRACING ENTRIES TO OR EXITS FROM A DYNAMIC LINK LIBRARY, Ser. No. 08/763,136, U.S. Pat. No. 5,946,486. However, it will be appreciated that the present invention may be implemented using other tools, apparatuses and methods.
The present invention provides a method, implemented in an information handling system, for selecting one or more dynamic link libraries (DLLs), utilized in an application program, to be demand loaded. The method comprises the steps of identifying a DLL reference by the application program; tracing outputs from the DLL; examining the traced output of the DLL to determine whether the DLL was executed; and selecting the DLL to be demand loaded if the DLL was not executed.
The present invention also provides a computer program product implemented in a computer system for implementing the above-described method.
The present invention also provides a computer program product comprising a program of instructions including a DLL, a shadow DLL, and wherein the shadow DLL includes code for tracing events occurring upon entries to or exits from the DLL and code for demand loading the DLL.
The present invention also provides an information handling system including one or more processors, memory and a program of instructions including a DLL, a shadow DLL, and wherein the shadow DLL includes code for tracing events occurring upon entries to or exits from the DLL and code for demand loading the DLL.
The present invention also provides a method and a computer program product, implemented in an information handling system, for determining a minimum time saved in the execution of an application program having one or more dynamic linked libraries (DLLs) by demand loading the DLL. The method includes the steps of generating a shadow DLL for tracing entries to or exits from a DLL and for demand loading the DLL; loading the shadow DLL upon reference by the application program; and measuring the time to execute the application program to determine a minimum time saved by demand loading the DLL.
The main advantage of the present invention is providing DLL demand load analysis without modification to the DLL or application program.
Another advantage of the present invention is providing an apparatus and method for providing a demand load analysis tool which automatically generates a shadow DLL for tracing events occurring upon entry to or exit from a DLL and for demand loading the DLL without modifying any code of the DLL and without adding substantial processing overhead to the DLL.